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What  Changes  Are  Needed  to  POSIX  to  Satisfy 
Missile  and  Aviation  System  Requirements? 

How  Can  We  Know? 


•  Test  Many  Different  Systems  by  Implementing  Them  on  Top 
of  POSIX. 

-  Expensive! 

-  Takes  too  long!  .  or 

•  Implement  MetaH  on  Top  of  POSIX. 

-  MetaH  satisfies  a  broad  range  of  current  and  anticipated 
missile  and  aviation  systems. 

-  Cost  is  reasonable. 

-  Will  provide  quantitative  results  for 

•  performance. 

•  adequacy  of  current  POSIX  features  with  recommendations 
for  enhancements  and/or  new  features. 

-  Leverages  POSIX  into  DARPA  rapid  development  environment. 
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Synergism  and  Integration  Path 


DARPA  Technology 
•Evolution 
•Architecture 
»Low  cost  retargeting 
•High  Assurance 
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Society  of  Automotive  Engineers 
Generic  Open  Architecture  Stack 


Class  4D 


Class  3D 


Class  2D 


Class  1 D 
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External  Environment  Interface 


Honeywell 


Architectural  SW  Backplane 


•  Strong  Partitioning  -  Not  Just  Memory  Protection  But  Also  ... 

•  Timing  Control 

•  Process  Control 

•  Interface  Control 


OPERATING  ENVIRONMENT  METAH  KERNEL 

EMBEDDED  HARDWARE  TARGET 


format  April  98.ppt  5/12/98 


Honeywell 


MetaH/POSIX  Goals 


•  Discover  missing  required  capabiiities  for  Avionics 

•  Reduce  adoption  barriers  for  MetaH  and  SAE/POSiX  by 
working  with  programs,  vendors  to  meet  requirements 

•  Refiect  advanced  Avionics  requirements  into  SAE/POSIX 
standards 

•  Demonstrate  usability 

•  Leverage  POSIX  and  related  Standards  into  advanced 
DARPA  Developments 

•  Start  standardization  of  MetaH  Achitecture  Description 
Language  for  Avionics 
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MetaH/POSIX  97  Evaluation  Study 


Objectives 

•  Assess  benefits  of  achievable  portability  using  real-time 
POSIX 

•  Assess  suitability  of  real-time  POSIX  for  MetaH-produced 
missile  and  helicopter  avionics  software 

•  Identify  possible  POSIX  and  MetaH  enhancements 

Methodology  /  Tasks 

•  Survey  POSIX  documents  and  vendors 

•  Survey  missile  and  helicopter  program  requirements 

•  Prototype  a  MetaH  retarget  to  a  real-time  POSIX 
implementation 
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Missile  and 

Heiicopter  Requirements 


•  Functional 

•  Processor  time  and  space 

•  Development  process 
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Missile  and  Helicopter 
Functionai  Requirements 


•Some  functional  requirements  are  outside  POSIX  and  MetaH 
scope 

-  Initial  hardware  self-test 

-  Memory  management,  e.g.  ROM-to-RAM  code  copies 

-  Low-level  error  management,  e.g.  lock-step  pair  restart 

-  Hardware  device  interfaces 

•  Missile  and  helicopter  functional  requirements  were  largely 
inferred  from  MetaH  requirements 

-  MetaH  is  emerging  technology 

-  Incorporates  methods  widely-used  in  practice 

-  Incorporates  methods  that  anticipate  future  systems 
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Missile  and  Helicopter 
Time  and  Space  Requirements 


Some  data  obtained  from 

•  OH-58D  helicopter  (Kiowa  Warrior) 

•  Patriot  Anti-Cruise  missiie  (PACM) 

•  Theatre  High-Aititude  Air  Defense  (THAAD) 

•  Army  Tacticai  Missiie  System  (Army  TACMS) 

•  Inertiai  Fiight  Measurement  Unit  (Honeyweii  IFMU) 


Missile  Profile  Helicopter  Profile 

Multi-processor  Multi-processor 

Some  Heterogeneous  DSP+GPP  Heterogeneous  DSP/GPP 

1MB  memory/processor  10MB  memory/processor 

500Hz  high  rate  50  Hz  high  rate 

Some  security 
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Missile  and  Helicopter 
Development  Process  Requirements 


•  Verification 

-  RTOS  must  be  verified,  too 

-  Partitioning 

•  Multi-Platform  Development 

-  Workstation  testbed  fiight  system 
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Integrated  Tools  for  Integrated  Avionics 


Management  (ICE) 
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MetaH  Discriminators 


Not  a  traditional  CASE  tool 


specialized  for  hard  real-time,  fault-tolerant,  safely/securely 
partitioned,  scalable  multi-processor  systems 

integration  toolset  with  open  interfaces  to  domain-specific 
generators,  re-engineering  tools,  module  libraries,  etc. 

closely  couples  formal  modeling  and  analysis  with  design 
and  implementation 

attentive  to  software/hardware  interface,  multi-processor  systems, 
software/hardware  configurability  and  protability 


Not  a  traditional  Real-time  Operating  System 

designed  to  be  retargeted  to  desired  execution  environment, 
including  existing  real-time  run-times/kernels/operating  systems 

application-specific  executive  is  tailored  for  each  application, 
off-line  configuration  enables  faster  and  smaller  executives 
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MetaH  Toolset 


Source  Modules 

Re-engineered 

Hand-Coded 


Executive 

Generator 


t 


I 


Workspace 


HW/SW 

Binder 


Schedulability 

Reliability 

Partition  Impact 

Concurrent 

Modeler 

Modeler 

Modeler 

Process  Modeler 

Load  Image  Analysis  Results 
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MetaH  Executive 


Automatically  Generated  MetaH 
Executive  Code 


MetaH  Executive  Library  Components 
Target-Specific  Library  Components 


RTOS 


Processor  A 
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Glue”  Code 


Processor  B 
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Prototype  Technical  Approach 


•  Design  Decisions 

-  Where  does  MetaH  glue  code/function  go? 

-  How  do  processes  communicate  with  MetaH  executive? 

-  How  is  the  MetaH  process  life  cycle  managed? 

-  How  are  MetaH  shared  objects  implemented? 

-  How  is  MetaH  message  passing  implemented? 

-  How  is  synchronization  supported? 

•  Aiternatives  and  Seiections 

-  Try  to  support  full  MetaH 

-  Try  to  use  simplest,  most  direct  choices 
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Summary  of  Effort 


•  POSIX  documents  and  tools  reviewed,  tools  selected 

•  Prototype  based  on  POSIX  was  partially  functional 

•  Much  of  the  prototyping  effort  was  spent  filling  POSIX 
gaps  and  bugs  (we  filled  in  vendor’s  gaps  using  FSU 
Florist) 

•  About  70  objects  from  1 1  POSIX  packages  referenced 

•  Recommendations  presented  to  SAE  and  POSIX 
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Portability  Conclusions 


•  Portability  is  limited  by  incomplete  implementations 

•  There  are  situations  where  significant  benefits  are 
possible  anyway 

-  Proven  architecture  concepts 

-  Some  source  portability 

-  Portability  from  workstation  to  testbed  to  flight  hardware 

-  Ease  processor  upgrades 

•  Allocate  your  own  resources  to  insure  an  appropriate 
implementation 
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Avionics  Requirements  Conclusions 


•  Neither  current  POSIX  standards  or  commercially  available 
implementations  are  likely  to  support  fully  partitioned 
MetaH  off-the-shelf 

•  Partially  partitioned  MetaH  on  a  reduced  vendor-specific 
POSIX  profile  is  possible  and  would  meet  requirements  of 
many  helicopter  systems 

•  Unpartitioned  MetaH  with  restricted  aperiodic  scheduling  on 
a  reduced  vendor-specific  POSIX  profile  or  on  Ada95  is 
possible  and  would  meet  requirements  of  many  missile 
systems 
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Recommendations 


Desired  POSIX  enhancements 

•  Support  for  adaptive  real-time  scheduling 

•  Support  for  partitioning 

•  Support  for  extended  executives 

Desired  MetaH  enhancements 

•  Subsets  for  minimal  RTOS  configurations 

•  Improved  event  processing 

•  Standard  10  and  device  interfaces 
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1998  Plans 


Begin  Metah  standardization  process 

Preiiminary  evaiuation  of  the  foiiowing  activities,  foiiowed  by 

seiection  and  focus  on  one 

-  Extend  work  on  POSIX,  MetaH  and  LynxOS  to  support  and  demo 
efficient  fully  partitioned  and  adaptively  scheduled  multi¬ 
processor  systems 

-  Prototype  POSIX,  MetaH  and  pAOS  to  support  and  demo 
efficient  fully  partitioned  and  adaptively  scheduled  multi¬ 
processor  systems 

-  Incorporate  a  UDI  interface  capability  in  MetaH  and  experiment 
with  available  devices  and  drivers. 


preliminary 

evaluation 


final 

report 


IQ  98 


2Q  98 


3Q  98 


4Q  98 
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Additional 

Information 
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MetaH  Scheduling 
and  Allocation  Features 


•  Periodic  and  aperiodic  processes 

•  Preperiod  deadlines  and  communication 

•  Process  criticalities 

•  Multiple  user-selectable  real-time  semaphore  protocols 

•  Hard  real-time  multi-processor  port-to-port  communication 

•  Dynamic  reconfiguration  of  processes  and  connections 

•  Processor  and  channel  real-time  schedulability  analysis 

•  Constraint  specifications  for  software/hardware  binding 

•  Process  chaining  for  undeiayed  messages  and  ordering 

•  Siack  scheduiing  of  aperiodic,  incrementai,  queue  server 
processes 

•  Muitipie  subtasks  within  muitipie  threads 


format  April  98.ppt  5/12/98 


Honeywell 


MetaH  Partitioning  Features 


•  Processes  are  allocated  individual  protected  address  spaces 

•  Execution  time  iimits  can  be  specified  and  enforced 

-  Elaboration  time 

-  Initialization  time 

-  Compute  time 

-  Semaphore  locking  time 

•  Process  scheduling  criticalities  can  be  specified 

•  Process  only  has  the  run-time  capabilities  granted  in  the 
specification 

•  Communication,  data  access  and  scheduiing  interference 
checked  against  specified  safety/certification  /eve/  and  data 
rights  attributes 
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MetaH  Fault-Tolerance  Features 


•  Default  behaviors  for  unhandled  application  process 
exceptions 

•  Process  time  limits  and  criticalities  to  handle  timing  faults 

•  Communication  and  semaphore  protocols  detect  and  report 
faults 

•  Plug-replaceable  inter-processor  executive  concensus 
protocol 

•  Error  models  and  fault  attributes  allow  specification  and 
reliability  modeling  of  redundancy  management 
architectures 

•  Dynamic  reconfiguration  (mode  changes)  with  processor 
restart 

•  Event  concensus  expressions  for  fault-tolerant  mode 
changes 
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MetaH  Hardware  Specification  Features 


•  Retargetable  to  selected  language  toolset  and  RTOS 

•  Software/hardware  interface  features:  hardware  ports, 
hardware  monitors,  hardware  events 

•  Processor  and  device  specifications  identify  driver  and 
interface  source  moduies 

•  Channel  specification  used  to  connect  processors  in 
arbitrary  topologies 

•  Decrease  retargeting  effort  through  standard  interfaces: 
Ada95,  POSiX,  UDi, . . . 

•  Extend  distributed  scheduiing  to  handie  tow-bandwidth, 
high-latency  channels,  e.g.  1553,  CAN,  ARINC  659, . . . 
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Where  does  MetaH  Glue 
Code/Function  Go? 


•  Map  all  MetaH  services  to  POSIX  services 

•  Include  executive  code  in  application  processes 

•  Add  executive  code  to  RTOS  kernei 

•  Executive  code  in  a  separate  POSIX  process 
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How  do  Processes  Communicate  with 
the  MetaH  Executive? 

•  Traps,  inter-address-space  procedure  calls 

•  Shared  memory  for  parameters  and  results 

•  Messages  for  parameters  and  results 

•  Semaphores  for  call/return  synchronization 

•  Signals  for  call/return  synchronization 
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MetaH  Process  Life  Cycle 


Process 

Creating 
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How  is  the  MetaH  Process 
Life  Cycie  Managed? 


•  Process  restart  service 

•  Process  start  and  terminate  service 

•  Generate  “wrapper”  for  each  process 
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How  are  MetaH  Shared 
Objects  Implemented? 


•  Linker  overlays 

•  Ada95  shared  passive  packages 

•  Shared  memory  objects  and  generated 
address  clauses 
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How  are  MetaH 
Messages  Implemented? 


•  POSIX  message  services 

•  Assignments  through  shared  memory  objects 
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How  is  Synchronization  Supported? 


•  Applications  directly  use  POSIX 
services 

•  MetaH  semaphores  built  using 
POSIX  services 
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Summary  of  Effort 


•  Total  evaluation  (including  surveys  and  paperwork)  about  4MM 

•  Partially  functional  prototype  produced 

-  Preprocessing,  compile,  link  by  hand 

-  Ran  some  simple  examples 

-  Several  features  unimplemented 

•  Code  referenced  about  70  objects  from  1 1  POSIX  packages 


POSIX 
POSIX  lO 


POSIX_PROCESS_IDENTIFICATION 
POSIX  PROCESS  PRIMITIVES 


POSIX_MEMORY_LOCKING  POSIX_PROCESS_SCHEDULING 

POSIX_MEMORY_MAPPING  POSIX_SHARED_MEMORY_OBJECTS 
POSIX_MESSAGE_OUEUES  POSIX_SIGNALS 

POSIX  PERMISSIONS 
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Our  Portability  Experiences 


•  Commercial  products  offer  a  subset  of 
what  we  wanted 

•  We  filled  in  gaps  using  Florist  from  FSU 

•  We  spent  a  lot  of  time  on  POSIX  interface 
implementation 
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Portability  Benefits 


•  Common  and  proven  architecture  and  design  concepts 

•  Some  source  code  portabiiity 

•  Portabiiity  is  aiways  iimited  by  appiication  dependence 

•  Process  portabiiity:  workstation  testbed  fiight  system 

•  Ease  processor  upgrades  to  reduce  recurring  hardware  cost 
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Possible  POSIX  Enhancements 


•  Control  child  priority  at  start 

•  Control  child  process  thread  priorities 

•  Chiid  process  restart  (running  and  terminated) 

•  Execution  time  monitoring,  limiting,  stop/continue 

•  Restrict  chiid  cails  that  impact  scheduling,  memory 
aiiocation 

•  Semaphore  semantics  to  handie  fauit  while  locked 

•  Rapid  parent/chlld  service  request  (e.g.  passive  parent) 
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Possible  MetaH  Enhancements 


•  Additional  Semaphore  Capabilities 

-  Conditional  variables 

-  Mutexes 

•  Unpartitioned  MetaH 

-  Identical  defect-free  semantics 

-  Identical  RTOS  interface,  or  at  least  identical 
MetaH-  generated  code 

•  Simplified  aperiodic  protocols 

•  Additional  event  selection  &  queueing  features 
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Other  Documents  and  Standards 


•  Proposed  POSIX  additional  realtime  extensions 

•  Proposed  POSIX  application  environment  profiles 

•  Proposed  realtime  distributed  communications 

•  SAE  Generic  Open  Architecture  (GOA)  framework 

•  Uniform  Driver  Interface  (UDI) 

•  Intelligent  Input/Output  (I2O) 
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Draft  POSIX  Additional 
Realtime  Extensions 


•  MetaH  designed  to  easily  add  selectable  semaphore 
protocols,  can  pass  reader/writer  and  spin-lock  capabilities 
on  to  application  processes.  Multi-processor  protocols  in 
particular  offer  complex  trade-offs 

•  Interface  to  shared  storage  pools  across  multiple 
processors  should  be  as  compatible  as  possible  with  shared 
memory  object  interface,  e.g.  shared  memory  objects  come 
from  local  storage  pool 

•  MetaH  needs  system-wide  periodic  signal  driveable  from 
synchronized  system  clock 
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Draft  POSIX  Application 
Environment  Profiles 


•  Minimal  Realtime  System  Profile  is  a  reasonable  baseline 
for  flight  systems 

•  Desire  process  interfaces  for  upward  compatibility,  with 
suitably  limited  semantics 

•  Full  processes  with  protected  address  spaces  and  time 
partitioning  would  be  suitable  for  IMA  systems 
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Realtime  Distributed  Communication 


•  MetaH  would  create  endpoints  and  connections  between 
executives  on  different  processors  at  start-up 

•  Would  like  to  send  different  object  types  (or  at  least 
subtypes)  over  connections 

•  Directory  services  shouldn’t  be  essential  for  this 

•  Buffer  management,  configuration,  and  heterogeneous 
systems  support  useful  (heterogeneous  languages,  too) 

•  MetaH  requires  a  communications  scheduiabiiity  modei 

•  MetaH  manages  end-to-end  system  scheduiing  and  analysis, 
interface  to  a  communications  iink  is  by  timing  message 
reiease  and  requiring  a  deiivery  deadline 

•  Priority  is  not  directiy  meaningfui  for  many  types  of 
communications  iink  hardware 
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SAE  Generic  Open 
Architecture  Framework 


•  MetaH  executive  is  an  extended 
Operating  System  (XOS) 
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Uniform  Driver  Interface 
inteliigent  Input/Output 


•  POSIX  provides  interfaces  only  for  some  classes  of  devices, 
e.g.  mass  storage,  terminals 

•  MetaH  would  treat  UDI  modules  like  others  that  are  being 
selected  and  composed  into  an  application,  but  would  need 
to  support  a  UDI  environment  for  them 

•  Some  avionics  system  components  are  best  treated  as 
MetaH  devices  (lOPs)  rather  than  MetaH  processors,  e.g. 
smart  sensors,  smart-head  displays.  Integration  with  an  I2O 
toolset/environment  might  be  appropriate 
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Effort  Saved  Using  MetaH 

Estimated  37%  reduction  in  Totai  Effort 
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Complex  Systems  Engineering:  A  Multi- 
Disciplinary  Engineering  Process! 


Requirements 

Analysis 


Design 


Implementation 


Integration 


Honeywell 


Architecture:  The  Missing  Link 
in  Engineering! 


Requirements 


Design  and 
Impiementation 
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Paradigm  for  Architecture  Based 
Software  Development 


Honeywell 


Mapping  to  a  Modular  System 


•  Individual  Units  Map  to  Different  Areas 
of  Modular  System’s  Resources 
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